In a typical radio communications network, wireless terminals, also known as mobile stations and/or user equipments, UEs, communicate via a Radio Access Network, RAN, to one or more core networks. The radio access network covers a geographical area which is divided into cell areas, with each cell area being served by a base station, e.g., a radio base station, RBS, which in some networks may also be called, for example, a “NodeB” or “eNodeB”. A cell is a geographical area where radio coverage is provided by the radio base station at a base station site or an antenna site in case the antenna and the radio base station are not collocated. Each cell is identified by an identity within the local radio area, which is broadcast in the cell. Another identity identifying the cell uniquely in the whole mobile network is also broadcasted in the cell. One base station may have one or more cells. A cell may be downlink and/or uplink cell. The base stations communicate over the air interface operating on radio frequencies with the user equipments within range of the base stations.
A Universal Mobile Telecommunications System, UMTS, is a third-generation mobile communication system, which evolved from the second generation, 2G, Global System for Mobile Communications, GSM. The UMTS terrestrial radio access network, UTRAN, is essentially a RAN using wideband code division multiple access, WCDMA, and/or High Speed Packet Access, HSPA, for user equipments. In a forum known as the Third Generation Partnership Project, 3GPP, telecommunications suppliers propose and agree upon standards for third generation networks and UTRAN specifically, and investigate enhanced data rate and radio capacity. In some versions of the RAN as e.g. in UMTS, several base stations may be connected, e.g., by landlines or microwave, to a controller node, such as a radio network controller, RNC, or a base station controller, BSC, which supervises and coordinates various activities of the plural base stations connected thereto. The RNCs are typically connected to one or more core networks.
Specifications for the Evolved Packet System, EPS, have been completed within the 3rd Generation Partnership Project, 3GPP, and this work continues in the coming 3GPP releases. The EPS comprises the Evolved Universal Terrestrial Radio Access Network, E-UTRAN, also known as the Long Term Evolution, LTE, radio access, and the Evolved Packet Core, EPC, also known as System Architecture Evolution, SAE, core network. E-UTRAN/LTE is a variant of a 3GPP radio access technology wherein the radio base station nodes are directly connected to the EPC core network rather than to RNCs. In general, in E-UTRAN/LTE the functions of a RNC are distributed between the radio base stations nodes, e.g. eNodeBs in LTE, and the core network. As such, the Radio Access Network, RAN, of an EPS has an essentially “flat” architecture comprising radio base station nodes without reporting to RNCs.
According to the latest discussions in 3GPP, a problem has been reported in R3-131285, “Impact on MRO from RRC re-establishment”, Huawei, Fujitsu, CATT, RAN3 #81. The so-called ambiguity problem is that the UE reports the cell ID of the cell where a re-establishment of a connection, after a lost connection, will be attempted when the suitable cell is selected, and not when the re-establishment is completed, while the eNB will generate the Radio Link Failure, RLF, indication for each attempted re-establishment, independent if it is completed, succeeded or rejected, or incomplete. This leads to a problem of ambiguity in that not knowing whether the re-establishment cell is to be considered during a Mobility Robustness Optimization process or not.
Two solutions have been proposed to this problem in R3-131285. Both solutions rely on providing additional information to the eNB receiving the RLF indication. One solution is UE-based solution and the other solution is a network-based solution.
In the UE-based solution, the RLF report is modified to perform either of the following:                Include an indicator in the RLF report to indicate whether the re-establishment was successful or rejected, or incomplete/failed;        Only include re-establishment cell ID if the re-establishment was either successful or rejected;        Include the causes of the failed re-establishment in the RLF report, such as, for example, no suitable cell can be selected, the selected cell is no longer suitable, the RRC re-establishment request is rejected, etc.        Only send RLF Report when the re-establishment was either successful or rejected.        
Although this UE-based solution is quite straightforward, it would require that the UE behavior to be modified. In addition to this, it would only solve the so-called ambiguity problem for Release12 UEs and not for legacy UEs, that is, it would not work for pre-Release 11 UEs or for UEs that do not support the enhancements as proposed by this UE-based solution.
In the network based solution, the basic idea is to add a flag into the first RLF indication, which is triggered by the re-establishment. This information can be stored in the receiving eNB and combined with a second RLF indication, which is triggered by the RLF report. This is possible since Release11 because the C-RNTI was added to the RLF report. This enables the eNB receiving the two RLF indications to match the RLF indications from the same event.
At re-establishment, the eNB sending the RLF indication would include the outcome of the re-establishment, and the eNB receiving this RLF indication would store: the C-RNTI, the time the RLF indication was received, and the reported outcome of the re-establishment. Thus, when the eNB receives the RLF indication triggered by the reception of an RLF report, the eNB can use the reported C-RNTI and a timer value, e.g. the time between failure and reporting, to retrieve the previously stored information. Alternatively, the eNB may also include this information in the HO report, if sent.
This network-based solution would be more complex for the eNB and would require some significant change in the X2AP RLF Indication. It would require the eNB to store the C-RNTI, the time the RLF indication was received and the reported outcome of the re-establishment for long periods of time, e.g. up to 48 hours, in order to possibly combine with a second RLF indication.
Both these solutions will thus affect the performance of the radio communications network, for example, by not affecting legacy user equipments and involving a complex alteration in the eNB.